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1.  INTRODUCTION 

A  criticality  analysis  is  the  term  used  to  describe  the  vulnerability  of  a  combat  vehicle  from  the  perspective  of  an 
automotive  engineer  who  understands  the  purpose,  function,  and  design  of  the  vehicle.  The  most  basic  unit  that  is 
used  in  its  construction  is  that  of  the  critical  component *  A  criticality  analysis  does  not  itself  describe  the  vulnera¬ 
bility  of  its  constituent  components;  there  are  other  tools  as  well  as  test  firings  that  are  designed  for  this  purpose. 
Instead,  the  focus  of  the  criticality  analysis  is  to  describe  how  the  components  work  together  as  a  system  to  support 
the  various  functions  of  the  vehicle.  Much  of  this  can  be  accomplished  with  the  aid  of  engineering  drawings  and 
verified  by  nondestructive  testing,  where  one  simply  disconnects  wires  or  components  and  notes  the  effect  upon 
vehicle  function.  The  main  emphasis  is  on  the  logical  and  engineering  relationships  of  the  components,  rather  than 
the  components  themselves.  In  order  to  deal  with  the  engineering  complexity  of  a  modem  combat  vehicle,  an  ana¬ 
lyst  will  usually  approach  the  task  in  a  hierarchical  manner.  First,  critical  components  are  identified  and  assembled 
into  subsystems;  next,  subsystems  are  assembled  into  systems;  and  finally,  systems  are  assembled  into  the  various 
functions  of  the  vehicle,  such  as  mobility,  communications,  firepower,  etc.  Fault  trees  are  the  basic  building  blocks 
used  in  this  construction  of  a  criticality  analysis. 


This  report  deals  with  two  aspects  of  fault  trees  and  the  role  they  play  in  a  criticality  analysis:  how  to  represent  them 
and  how  to  evaluate  them.  Fault  trees  have  been  represented  as  deactivation  diagrams ,  an  example  of  which  is 
shown  in  Figure  1. 


Figure  1.  Example  deactivation  diagram. 

This  particular  deactivation  diagram  is  made  up  of  five  critical  components,  a,  b,  c,  d,  and  e.  The  system  that  this 
deactivation  diagram  represents  is  considered  fully  functional  if  and  only  if  there  is  at  least  one  complete  path  from 
the  top  node  to  the  bottom  node  of  the  diagram.  If  there  is  no  such  path,  the  system  is  considered  completely  non¬ 
functional.  The  more  common  term,  which  we  shall  use,  is  “killed.”  Components  are  also  treated  as  having  only 
two  states:  functional  or  killed.  Now  notice  that  this  diagram  has  three  possible  paths  so  there  is  a  certain  amount  of 
redundancy  that  helps  to  reduce  the  vulnerability.  Let’s  suppose  that  components  b  and  e  are  killed.  Then  we  still 
have  a  complete  path  through  a  and  d.  As  far  as  the  system  is  concerned,  it  would  still  be  considered  fully  func¬ 
tional. 

Deactivation  diagrams  are  also  commonly  referred  to  as  fault  trees.  In  this  report  we  make  the  distinction  that  a 
deactivation  diagram  will  refer  to  the  actual  diagram  or  figure,  whereas  a  fault  tree  will  represent  the  abstract  logical 
structure  that  the  diagram  represents.  For  example,  in  Figure  1,  components  b  and  c  are  arranged  in  series  and  com¬ 
ponents  d  and  e  are  arranged  in  parallel.  One  of  the  goals  of  this  report  is  to  provide  a  structure  that  captures  this 
information  without  requiring  a  diagram.  Deactivation  diagrams  are  fine  for  illustrating  fault  trees,  but  that  is  also 
their  limitation.  Often  they  are  just  figures  in  a  report  and  cannot  be  used  by  other  software.  Even  if  they  are  written 
in  terms  of  a  software  drawing  program,  they  describe  the  layout  of  the  figure,  not  the  logical  relationships  between 
components;  the  emphasis  is  on  appearance  rather  than  logical  structure.  The  other  goal  of  this  report  is  to  show  that 
there  is  a  very  simple  and  efficient  way  to  evaluate  systems  from  their  fault  trees  that  avoids  having  to  consider  every 
possible  path  through  the  deactivation  diagram. 

*  The  critical  components  that  are  used  in  a  criticality  analysis  are  at  the  level  of  a  Line  Replaceable  Unit  (LRU). 
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2.  A  (VERY)  BRIEF  INTRODUCTION  TO  XML 

The  Extensible  Markup  Language  (XML)*  will  be  used  to  represent  fault  trees.  Here  we  give  a  short  synopsis  of 
this  language.  Actually,  XML  is  better  characterized  as  a  meta-language  for  creating  other  languages.  It  achieves 
this  by  providing  a  means  of  creating  markup  (also  called  tags),  which  can  then  be  embedded  in  a  document  to 
describe  its  structure.  Unlike  HTML  (Hypertext  Markup  Language),  which  has  a  fixed  set  of  predefined  tags,  the 
tags  in  XML  are  open-ended  and  of  our  own  choosing.  The  particular  meaning  (semantics)  and  rules  (grammar)  that 
we  give  to  the  tags  must  be  described  in  a  Document  Type  Definition  (DTD),  and  so  this  is  an  ancillary  file  that  must 
accompany  the  structured  document.* 

The  idea  of  using  tags  to  describe  a  document’s  structure  was  the  original  intention  of  HTML,  but  over  the  years 
these  tags  have  become  more  commonly  used  for  controlling  the  document’s  appearance  in  a  Web  browser.  The 
emphasis  in  XML  is  on  content  rather  than  appearance  since  the  whole  purpose  of  the  tags  is  to  provide  a  facility  for 
describing  document  structure,  and  as  such,  is  independent  of  how  it  might  appear  in  a  Web  browser.  In  fact,  it  is 
only  recently  that  browsers  have  become  capable  of  displaying  XML  directly.  It  turns  out,  however,  that  this  is  not 
really  a  practical  limitation,  since  there  are  other  means  of  displaying  XML  in  Web  browsers. 

The  syntax  in  XML  is  stricter  than  that  of  HTML.  Every  opening  tag  must  have  a  closing  tag  unless  it  is  an  empty 
tag.  An  opening  tag  has  the  form 

<eleraent>,  ■  ’•  :-V’ 

where  element  is  the  name  that  we  give  to  the  tag.  A  closing  tag  has  the  form 

</element>,  •  •  ;  V  ’  ■■  '  •  •'  •;  ■  '■if  -- 

and  an  empty  tag  has  the  form 
<element/>. 

Tags  can  also  have  attributes,  in  which  case  they  have  the  form 
<element  attribute«"value,'>. 

Document  content  takes  on  a  well-defined  meaning  when  it  it  sandwiched  between  an  opening  and  a  closing  tag,  and 
it  is  in  this  way  that  the  document  becomes  structured.  What  makes  all  of  this  work  is  something  called  an  XML 
Parser.  This  is  a  piece  of  software  that  understands  tag  syntax  irrespective  of  our  particular  tag  semantics.  Parsers 
have  been  written  for  many  different  programming  languages.  At  a  minimum,  parsers  will  automatically  check  for 
proper  tag  syntax.  Validating  parsers  go  further  and  check  that  the  document  conforms  to  the  grammar  embodied  in 
the  DTD. 

This  introduction  barely  scratches  the  surface,  but  it  is  enough  for  our  purposes.  The  essential  point  is  that  XML 
allows  us  to  construct  a  markup  language  that  can  be  used  to  describe  fault  trees.  XML,  along  with  its  associated 
technologies,  is  a  burgeoning  area  in  the  software  industry,  and  there  are  many  resources  available  online  that  pro¬ 
vide  further  information.* 

3.  FAULT  TREE  REPRESENTATION 

We  describe  a  Fault  Tree  Markup  Language  (FTML)  with  the  following  list  of  capabilities. 

•  A  fault  tree  written  in  FTML  will  be  able  to  generate  both 

(1)  the  deactivation  diagram,  and 

(2)  the  sysdef  code  that  MUVES  [1]  requires. 

•  It  can  be  read  (parsed)  and  used  (interrogated  and  manipulated)  by  other  programs. 

•  The  complete  specification  of  the  open  source  language  is  available  at  www.w3.org/TR/REC-xml. 

t  It  is  also  possible  to  include  the  DTD  directly  in  the  document  In  general,  it  can  have  both  external  and  internal  parts  and  has  the  syntax 
< !  DOCTYPE  Root  element  SYSTEM  ExternalDTD  [  InternalDTD\  >,  where  RootElement  is  the  actual  name  of  the  root  ele¬ 
ment,  Externa  1DTD  is  the  name  of  the  DTD  file,  and  the  square  brackets  contain  any  DTD  definitions  not  contained  in  the  external  file. 
Note  that  the  square  brackets  must  be  present;  they  do  not  have  their  common  meaning  of  indicating  an  option. 

t  For  example,  just  type  in  the  keyword  XML  at  www.google.com. 
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•  It  is  written  as  a  standard  text  file — which  makes  it  easy  to  edit  and  platform  independent. 

•  It  can  be  verified  (checked  for  proper  syntax)  and  validated  (checked  for  proper  grammar). 

Of  course  we  also  need  to  write  the  software  that  makes  use  of  the  parser,  extracts  the  information  and  then  displays 
it  in  various  ways  from  deactivation  diagrams  to  sysdef  computer  code.  We  will  show  how  this  can  be  done  in  a 
Web-scripting  language.  But  our  first  task  is  to  describe  the  language  itself. 

3.1  Fault  Tree  Markup  Language  (FTML) 

Fault  trees  are  composed  of  critical  components,  or  other  fault  trees,  that  are  arranged  in  a  combination  of  series 
and/or  parallel  structure.  As  such,  we  need  a  language  that  can  be  used  to  describe  both  a  fault  tree  and  a  component 
(which  will  then  act  as  nouns  of  the  language).  We  also  need  to  describe  series  and  parallel  arrangement  of  compo¬ 
nents  (verbs).  Finally,  the  components  and  fault  trees  have  certain  attributes,  such  as  a  name  and  an  identifier  (adjec¬ 
tives).  XML  is  ideally  suited  for  this  purpose.  As  we  already  mentioned,  tags  defined  through  XML  can  be  used  to 
describe  the  content  of  a  document  rather  than  its  formatting  appearance.  In  our  case  the  content  is  precisely  the 
fault  tree  structure  itself. 

First,  we  define  the  semantics  of  the  language  by  defining  valid  tags  and  attributes,  as  summarized  in  Table  1.  The 
actual  grammar  of  the  language  is  embodied  in  the  DTD,  to  be  described  later  (see  section  3.2). 


Table  1.  Tags  and  attributes  of  FTML. 


Meaning 

Element 

Value  T^pe 

Example 

Fault  Tree 

ft 

string 

string 

<ft  id=" 5"  name*" fuel_systemn> 

</ft> 

Component 

c 

ft 

id 

name 

(  true  |  false  ) 

string 

string 

<c  id*"  1234 "  name*" lef t_track"/> 
The  default  is  ft=" false" 

Notice  that  this  is  an  empty  tag. 

Series 

s 

none 

not  applicable 

<s> 

</s> 

Parallel 

p 

none 

not  applicable 

<p> 

</p> 

a  The  order  of  the  attributes  is  immaterial.  For  example,  <c  id="l"  name="a"/>  can  also  be  written  as  <c  name="a"  id="l"/>. 


These  four  tags  and  the  three  attributes  are  all  there  is  to  the  language.  This  makes  FTML  very  easy  to  learn,  and 
perhaps  the  quickest  way  to  learn  it  is  to  simply  code  some  fault  trees.  The  simplest  system  is  one  that  contains  only 
one  component.  An  example  of  this  is  the  supercharger  system  on  the  Paladin  [2];  its  deactivation  diagram  is 
depicted  in  Figure  2. 

1 

Blower  Housing 
(6048) 

~r 


Figure  2.  Example  of  a  single-component  deactivation  diagram. 

The  component’s  name  is  Blower  Housing  and  the  number  6048  is  referred  to  as  the  component’s  ident,  which  is  a 
unique  identifier.  This  fault  tree  expressed  in  FTML  is  as  follows: 

<?xml  version*Hl  .0I,?> 

< 1DOCTYPE  ft  SYSTEM 

<ft  id* "9*  name* M supercharger_sys  tem"  > 

<c  13**6048"  name* " bl.ower_„hous i ng " /> 

</ft> 

The  first  two  lines  of  this  file  are  boilerplate  and  will  be  the  same  for  all  fault  trees.  The  first  line  indicates  which 
version  of  XML  to  use.  (Currently,  there  is  only  one  version.)  The  second  line  indicates  that  the  root  tag  is  ft  and 
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that  the  full  DTD  is  located  in  a  file  called  ft .  dtd.  The  id  of  the  fault  tree  should  be  a  unique  identifier.  A  con¬ 
venient  choice — and  the  one  used  here — is  the  figure  number  of  the  deactivation  diagram  as  published  in  the  critical¬ 
ity  analysis  report. 


The  next  simplest  system  is  that  of  two  components  in  series.  An  example  of  this  is  the  left-front  shock  absorber 
system  of  the  Paladin,  as  shown  in  Figure  3. 


Figure  3.  Example  of  a  simple  series  deactivation  diagram. 


This  fault  tree  expressed  in  FTML  is  as  follows: 

<?xml  version**!,  0*?>  * v' 

:  < moCTYPE.  ft  SYSTEM  *£t.dtd"> 

■  <ft  Id-"!®"  name“*3hock„absorber_J.eft._frant_systein"> 

<S>  hvsV:-  ■  ..i 

<c  id*,"3610"  name«,*8hooKjnountlng_bracket_front_left"/> 

<c  id-"3611*  name-*ah4cskwcylinder_front_„l.eft"/> 

;>  </S>  Vs  '  K  i:  $lk- :'€: '■  ■"  'V "  ;  ■  :  :  ' 

</ft>  ...  V/f '’■■■  ''  V-  V; 

Notice  that  the  two  component  tags  are  simply  sandwiched  between  an  opening  and  a  closing  series  tag. 

Before  we  go  on,  let’s  make  some  adjustments  in  the  deactivation  diagrams.  Notice  that  the  component  names  can 
get  rather  long,  which  forces  us  to  use  larger  boxes  (or  smaller  fonts).  This  can  result  in  diagrams  that  span  more 
than  one  page  (or  have  names  that  are  difficult  to  read).  To  reduce  the  size  of  the  diagrams,  and  to  concentrate  on 
the  relationship  between  components,  we  will  use  boxes  of  a  standard  size  and  list  component  names  in  a  table, 
which  will  be  keyed  to  the  diagram  itself.  Figure  4  shows  the  above  diagram  in  this  standardized  form. 


c 

0 

Fault  Tree  16:  shock_absorber_left_front_system 

List  of  Critical  Components/Systems 

Label 

ID 

Name 

1 

3610 

shock_mountingJbracket_front_left 

2 

3611 

shock_cylinder_front_left 

Figure  4.  Simple  series  deactivation  diagram  in  standard  form. 

We  will  also  adopt  the  convention  of  always  using  lower  case  for  names  and  using  underscores  instead  of  spaces. 
Spaces  are  perfectly  acceptable  in  FTML,  but  underscores  will  prove  to  be  convenient  later  in  case  we  want  to  use 
the  name  as  a  variable  in  the  sysdef  code. 

Next,  is  an  example  of  a  system  consisting  of  two  components  in  parallel,  as  shown  in  Figure  5. 
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1 

II 

E 

II 

Fault  Tree  66:  f  ire_control_system 

List  of  Critical  Components  and/or  Systems 

Label 

ID 

Name 

1 

69 

automatic  fire  control  svstem 

2 

67 

backup  fire  control  svstem 

Figure  5.  Example  of  a  simple  parallel  deactivation  diagram* 

Shaded  boxes  will  indicate  that  the  “component”  is  actually  a  system  with  it’s  own  fault  tree.* 

This  fault  tree  expressed  in  FTML  is  as  follows: 

<?xml  version**"!  .  0"?> 

< I DOCTYPE  ft  SYSTEM 

<ft  id*=w66"  name«"f ire_control_system"> 

:  <p> 

<c  ft**" true"  id«*69"  name«"automatic_f ire__control_system"/> 

<c  ft«"true"  id»"67"  name- * ba ck up_f i r e_con t rol_sy s t em "  /> 

.  </P>  . 

</ft> 

Notice  that  the  system  names  are  underlined,  indicating  that  these  are  clickable  links  when  displayed  in  a  Web 
browser.  Clicking  on  them  brings  up  the  corresponding  deactivation  diagram  for  that  system.  Also  notice  that  the 
attribute  ft  has  been  set  to  true  to  indicate  that  these  “components”  are  systems  in  their  own  right.  (The  default 
value  for  this  attribute  is  false.)  This  attribute  will  prove  to  be  essential  when  we  wish  to  determine  the  proper 
order  for  evaluating  the  fault  trees. 

Notice  that  the  syntactic  structure  of  this  fault  tree  is  virtually  identical  to  the  series  fault  tree.  The  only  difference  in 
the  FTML  is  that  now  the  component  tags  are  enclosed  between  parallel  tags  instead  of  series  tags.  Notice  that 
series  and  parallel  tags  have  no  attributes.  It  may  also  be  worth  mentioning  again  that  the  attributes  in  components 
and  systems  can  be  in  any  order. 

Next  we  consider  a  system  that  has  a  combination  of  both  series  and  parallel  arrangement  of  components.  An  exam- 
pie  of  this  is  shown  in  Figure  6,  which  was  taken  from  the  Paladin  criticality  analysis  [3]. 


*  There  is  no  hard-and-fast  rule  for  the  distinction  between  components  and  systems,  as  it  depends  upon  the  context.  In  practice,  anything  that  is 
represented  with  a  deactivation  diagram  is  considered  a  system.  The  authors  of  the  criticality  analysis  on  the  Paladin  [3]  also  adopted  the  con¬ 
vention  of  using  the  suffix  system  to  aid  the  reader. 
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Fault  Tree  27:  left_segment_board__power_system _ _ 

List  of  Critical  Components  and/or  Systems 
Label  1  ID  |  Name 

1  9142  _ left_segment_board _ _____ 

2  9160  external_receptacle  _ 


3  9090  harness_ext_receptacle_to_left_segment_board 


Figure  6.  Example  of  a  deactivation  diagram  with  both  series  and  parallel. 

This  fault  tree  expressed  in  FTML  is  as  follows. 

<?xml  vers ion- 

< I DOCTYPE  ft  SYSTEM  "ft.dtd"> 

eft  id- "27"  name-"left_aegment_board_power„system"> 

<8>  '0.<  ^  ■  -Jr  .  : 

<c  id- " 9 1 4  2 "  name- " ief t_segment_boa rd " /> 

if  -  ■ '  ■  <p>  .  •;  .  :  '.f;  \ 

<S>  ' 

<c- id- *9160*  name-*  externa  l_.reoeptacleV> 

<c  id- "9090"  name- " harnes s_ext_recepta  cle_to_l  ef  t_.s egment.„board " /> 

</s>  :  "v':  ■ 

<s>  .  '•:-v  :;v  -■ 

:<c  id**.9j227*-''natwi-*|KMier^w^toJl^ft^8e9«neiitJx>«rd*A 

<p> 

<o  ft- "true*  id- "2 6"  name-"slave_receptacle_power_aystem"/> 

<c  ft— "true*  id— *25*  name- " battery_suppl i ed  jpower_sys tem "/> 

<c  ft-* true"  id- "24*  name-’engine_suppled_power_system"/> 

</p>  •'  •  '  ’•  •  . 

</s>  .•••• 

</P>  .•  V'.-  l  '  • 

</a>  -  --.^V 

</ft> 

The  knack  of  coding  fault  trees  comes  with  experience,  but  one  can  take  either  a  top-down  or  a  bottom-up  approach, 
or  some  combination  of  the  two.  For  example,  with  this  diagram,  we  might  find  it  easiest  to  use  a  bottom-up 
approach  by  first  handling  the  parallel  structure  of  components  5,  6,  and  7,  then  combine  that  result  with  component 
4  in  a  series  structure,  then  turn  to  the  left  path  and  combine  components  2  and  3  in  series,  then  combine  the  two 
parallel  paths,  and  finally  combine  that  result  with  component  1  in  series.  The  top-down  approach,  on  the  other 


hand,  would  first  recognize  that  what  we  have  essentially  is  component  1  in  series  with  some  combination  of  the 
rest.  The  combination  is  then  recognized  abstractly  as  a  parallel  structure.  The  parallel  structure  would  then  be 
expanded  in  terms  of  two  paths,  each  of  which  is  in  series,  etc.  In  the  bottom-up  approach,  we  are  regrouping  and 
collapsing,  whereas  in  the  top-down  approach  we  begin  with  the  overall  abstract  form  and  expand  out  from  there. 
Both  methods  of  coding  use  a  systematic  stepwise  approach.  Which  approach  to  use  is  simply  a  matter  of  taste;  the 
final  result  is  what  is  important,  not  how  we  get  there.  Later,  we  will  describe  tools  that  will  allow  us  to  generate  the 
deactivation  diagram,  and  this  will  then  provide  visual  confirmation  that  the  fault  tree  is  being  coded  properly. 

Any  mistakes  that  may  arise  in  coding  fault  trees  are  likely  to  be  due  to  lapses  in  concentration  rather  than  any  lack 
of  understanding  of  how  to  do  it.  This  is  because  the  coding  process  is  mostly  common  sense  and  doesn’t  require 
any  specialized  knowledge.  The  rules  used  in  coding  fault  trees,  which  are  embodied  in  the  DTD,  are  therefore 
mostly  to  avoid  these  types  of  errors. 

3.2  FTML  Content  Rules 

There  are  a  few  simple  content  rules  for  writing  valid  FTML. 

ft  There  must  be  exactly  one  ft  (fault  tree)  tag  per  fault  tree  file.  This  is  the  root  tag.  After  the  first  two  lines 
of  boilerplate,  there  must  be  an  opening  ft  tag  and  the  last  line  of  the  file  must  be  the  closing  ft  tag.  It  is 
a  requirement  of  XML  that  there  be  only  one  root  tag. 

c  There  must  be  at  least  one  c  (component)  tag  per  fault  tree  file.  If  there  are  two  or  more  c  tags,  they  must 
be  enclosed  by  either  an  s  or  a  p  tag. 

s  An  s  (series)  tag  must  enclose  either 

•  a  c  followed  by  another  c  or  a  c  followed  by  a  p,  or 

•  a  p  followed  by  either  a  c,  s,  or  another  p  tag. 
p  A  p  (parallel)  tag  must  enclose  either 

•  a  c  followed  by  either  another  c,  an  s,  or  a  p,  or 

•  an  s  followed  by  either  a  c,  another  s,  or  a  p,  or 

•  a  p  followed  by  either  a  c,  an  s,  or  another  p. 

The  complete  set  of  rules  for  FTML  is  embodied  in  the  DTD  shown  here: 

<1  ELEMENT  ft  (  C  |  S  |  p  )  >  :  ' 

<! ATTLIST  ft 

id  NMTOKEN  (^REQUIRED  :  :: 


nairie 

CD  AT  A 

♦REQUIRED 

<1  ELEMENT 

& 

( 

i  Ct 

( 

C  1 

p )+ 1 

i  ■ 

> 

( 

< 

c  I 

s  I  P 

)+  > 

> 

<1  ELEMENT 

p 

( 

(  C, 

< 

C  1 

e  |  p 

5+  )  1 

<  fir 

< 

C  1 

s  |  p 

)+  )  1 

i 

(  P/ 

c 

C  1 

s  |  p 

)+  ) 

>  :  V 

< i ELEMENT 

c 

EMPTY 

> 

<1 ATTLIST 

c  : 

ft 

( 

true 

i 

false  ) 

"false"  . 

id 

CDATA 

♦REQUIRED 

name 

CDATA 

♦REQUIRED 

> 


This  file,  although  cryptic,  concisely  and  completely  describes  valid  tags,  attributes,  and  content.  Once  a  fault  tree 
has  been  written  in  FTML,  it  can  be  validated  against  the  DTD.  For  example,  a  free  service  is  provided  by  the 
Scholarly  Technology  Group  at  Brown  University  (www.stg.brown.edu/pub/xmlvalid/),  which  allows  one  to  validate 
an  XML  document  online.  Not  only  does  it  check  for  syntax  errors,  but  it  will  also  check  that  the  document  con¬ 
forms  to  the  rules  expressed  in  the  DTD.  Current  versions  of  Web  browsers  that  have  the  capability  of  displaying 
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XML  will  also  display  FTML.*  However,  they  will  only  check  for  proper  syntax,  not  the  more  stringent  requirement 
of  conforming  to  the  DTD. 


3.3  Criticality  Analysis 

Once  all  the  fault  trees  have  been  coded,  they  need  to  be  assembled  into  a  criticality  analysis  file.  This  is  a  necessary 
step  before  software  can  analyze  dependencies  between  fault  trees.  Assuming  that  the  individual  fault  trees  reside  in 
files  with  names  of  the  form  f  t.  * .  f  tml,  then  the  following  shell  script,  ft2ca,  will  assemble  them  into  a  criti¬ 
cality  analysis  file  called  ca .  f  tml: 

# l/bin/sh  '■  ;  £•*;'■;  ■ 

#  £t2ca :  Assemble  the  criticality  analysis  file  from  the  individual  fault  tree 

#  files.  The  individual  fault  tree  files  must  have  names  of  the  form 

>  "ft.nftmi",  where  "♦•  is  usually  the  figure  number  of  the  fault  tree 

#  as  it  appears  in  a  report.  This  script  assembles  the  fault  trees  in 

#  ascending  order  on  figure  number  and  writes  to  stdout. 

echo  '<?xml  version- •1.0*?>' 

echo  '<1D0CTYPE  ca  SYSTEM  Hca.dtd">' 

echo  '<ca  name»*Criticality  Analysis  of  Paladin  M109A3E2*>' 
t.:.  fox  file  in  'Is  ft.*.ftml  |  sort  -n  -t.  +1' 

do  ’■  '■■■  ■  .:r  ■  v  ■  #Srg;;!:r 

cat  $fiie  |;grep  *v  "viarfion^  |  grep  -v  "DOCTYPE* 

?}'  done  '•  '  *  ■■ 

!<r  echo  '■  4  ’  ’  y!  4;' yy  vy  .:y>/:,.-:.  v  '  \ „  "v 

This  sample  script  is  for  the  Paladin;  the  name  should  be  changed  as  appropriate  for  another  vehicle.  The  criticality 
analysis  DTD  is  basically  the  fault  tree  DTD  with  the  change  that  the  root  tag  is  now  ca  instead  of  ft: 

<  I  ELEMENT  ca  {  ft  )+  > 

clATTUST  ca  ricJ  .  '  V *  ■' 

name  CDATA  # REQUIRED  r,y  '  . 

-  w  ,  ref  CDATA  #IMPLTED 

£  ■  note  CDATA  # IMPLIED  -  ,  . 

>  •  •  %  '  ;  .  :  ■  '  :  ..  '  -r 

:  <  1  ELEMENT  ft  (  C  |  S  |  P  )  >.  '  -i'7; 

L  ;  <1 ATTL1ST  ft  •-  p  '•/  '  .  J  ■■■/  ,v: 

r-,  id  nmtoken*REquired 


name 

CDATA 

♦REQUIRED 

>■  ■ 

< I  ELEMENT 

/S/’  - 

( 

(  c, 

( 

0  1 

P 

>+  ) 

i '  - 

J:i  ■ 

{  P# 

< 

c  I 

[  s 

ip 

■>+  > 

> 

<1  ELEMENT 

P  <; 

< 

(  c. 

< 

c  I 

3 

i  p 

y+  i  i 

<  s, 

< 

■  1 

i  p 

)+  >  i 

>. 

(  P/ 

< 

<3  | 

!  s 

i  p 

)+  ) 

> 

i, 

<1  ELEMENT 

c 

EMPTY 

> 

< l ATTLIST 

c  ■  '• 

ft 

( 

true 

i 

false 

)  ; 

"false" 

id 

CDATA 

•REQUIRED 

name 

CDATA 

•REQUIRED 

> 


Die  ca  tag  has  three  attributes:  name,  which  is  required;  ref,  which  is  an  optional  reference  such  as  a  published 
report;  and  note,  which  is  an  optional  note  which  documents  the  criticality  analysis  (such  as  assumptions  or  limita¬ 
tions).  A  criticality  analysis  must  consist  of  at  least  one  fault  tree.  Once  the  ca .  f  tml  file  has  been  constructed,  the 
software  described  in  this  report  no  longer  has  a  need  for  the  individual  fault  tree  files  and  they  can  be  safely  deleted. 

*  Incidentally,  the  display  of  FTML  by  current  browsers  looks  very  much  like  what  is  in  the  fault  tree  file,  including  indentation  (even  if  indenta¬ 
tion  is  not  in  the  original),  and  there  is  a  good  reason  for  this:  The  content  of  FTML  is  the  structure.  That  is  to  say,  the  only  structure  that  the 
browser  knows  about  is  the  tag  structure  based  upon  tag  syntax,  and  that  is  precisely  the  tree  structure  of  the  fault  tree.  This  is  another  reason 
why  fault  trees  are  such  a  natural  application  for  the  use  of  XML. 
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3.4  Fault  Tree  Tools 

FTML  is  an  XML-based  markup  language  for  describing  and  storing  fault  trees.  It  is  a  very  simple  language,  con¬ 
sisting  of  only  four  tags;  and  yet  these  four  tags  are  all  that  is  necessary  to  code  any  set  of  fault  trees  in  a  criticality 
analysis,  no  matter  how  complex.  As  a  language,  FTML  does  not  require  the  Web — provided  we  still  have  an  XML 
parser!  And  up  to  this  point,  the  only  use  we  have  made  of  FTML  is  to  provide  a  structure  so  that  fault  trees  can  be 
described  and  stored  as  text  files.  But  the  fact  that  XML  is  so  closely  associated  with  the  Web  means  there  are  sub¬ 
stantial  benefits  if  we  take  advantage  of  this  fact.  And  so  the  Web-scripting  language  of  PHP*  has  been  used  to 
design  some  Web-based  tools  that  extend  the  usefulness  of  FTML.  These  tools  are  able  to  display  a  criticality  analy¬ 
sis  in  a  Web  browser,  as  both  a  deactivation  diagram  and  as  MUVES  sysdef  code.  In  either  display  mode,  system 
names  are  formatted  as  hyperlinks,  in  order  to  facilitate  navigating  through  the  criticality  analysis.  Using  the  fault 
tree  in  Figure  6,  here  is  an  example  of  how  this  tool  displays  sysdef  code: 

left,  segment Jbcia rd_.power_ system  - 

left  segment__board  . -i'/v jfV. 

i  .  ■  ■  vw" 

c 

externa  l_recept.acle 

harness_ext_.receptaol  e„  to_left_segment_.board 

) 

& 

(  .  .  .  .  ' 

power_lead._to_J.eft_ segment  board  -  :*•;£ 

I  :  ■  •  ■  =;••'?. I  ' 

C 


)  \ 

);  :  -  •’  ■  v;  '  •  ■■  • 

This  Web-based  tool  also  has  the  capability  to  analyze  a  criticality  analysis  and  perform  the  following  functions: 

•  List  all  the  critical  components  along  with  their  idents; 

•  List  all  the  systems  along  with  their  IDs; 

•  Search  for  a  specific  component  and  list  all  its  idents; 

•  Search  for  a  specific  system  and  list  all  its  components; 

•  Find  all  the  systems  that  contain  a  given  component; 

•  Find  all  the  systems  that  contain  a  given  system  as  a  subsystem; 

•  Find  all  the  components  that  occur  more  than  once  along  with  the  systems  in  which  they  occur; 

•  Find  all  the  systems  that  contain  repeated  components. 

The  tool  will  also  analyze  dependencies  in  order  to  display  the  systems,  and  the  sysdef,  in  the  proper  order  for  evalu¬ 
ation.  If  there  are  cyclic  dependencies  among  the  systems,  this  will  be  detected  and  all  the  systems  involved  will  be 
listed.  Repeated  components  and  cyclic  dependencies  among  systems  become  important  when  it  comes  to  actually 
evaluating  fault  trees  (as  we  show  in  the  next  section). 

A  Web  browser  provides  an  excellent  environment  for  navigating  through  a  set  of  fault  trees  in  a  criticality  analysis 
and  should  be  particularly  helpful  in  the  actual  construction  of  the  criticality  analysis.*  However,  it  is  not  the  best 
medium  if  one  wants  a  record  of  the  criticality  analysis  that  can  be  included  in  a  report.  To  satisfy  this  need,  the  tool 
was  extended  to  provide  the  option  of  saving  the  criticality  analysis  as  a  PDF  document  (see  Figure  15  on  p.  22). 

•  This  is  an  open-source  language  that  is  available  online  at  www.php.net.  Originally,  PHP  stood  for  Personal  Home  Page  but  has  now  taken  on 
the  (recursive)  meaning  of  PHP  Hypertext  Preprocessor. 

t  Notice  that  the  tools  described  in  this  report  are  all  based  upon  the  FTML  text  file,  which  must  be  constructed  first  before  the  deactivation  dia¬ 
gram  can  be  displayed.  Another  tool  has  been  developed  recently  that  facilitates  the  construction  of  deactivation  diagrams  by  providing  a 
graphical  interface,  and  also  has  the  capability  of  writing  out  the  FTML  [4]. 


Finally,  in  order  to  facilitate  the  conversion  to  FTML,  another  tool  has  been  developed  which  converts  legacy  sysdef 
code  to  FTML. 

4.  FAULT  TREE  EVALUATION 

Evaluation  of  a  fault  tree  means  a  determination  of  whether  the  system  it  represents  is  functional  (not  killed)  or  non¬ 
functional  (killed),  given  the  state  of  each  of  its  constituent  components  (as  either  killed  or  not  killed).  There  are 
two  different  ways  that  a  fault  tree  can  be  evaluated.  One  is  based  on  Monte  Carlo  sampling,  and  the  other  is  based 
on  probability  algebra. 

4.1  Monte  Carlo  Sampling 

In  Monte  Carlo  sampling,  components  and  systems  are  represented  as  having  only  two  states:  either  killed  or  not 
killed.  We  will  use  1  ( true )  to  represent  a  killed  state  and  0  ( false )  to  represent  a  non-killed  state.  Given  that 
the  probability  of  killing  component  i  is  p,-,  one  performs  a  Bernoulli  trial  on  each  component  by  drawing  a  uniform 
random  number  r,  between  0  and  1 — more  precisely,  r,-  e  [0, 1) — and  assigning  the  state  kt  of  the  component 
according  to 

f  1  if  rf<Pi  (killed), 

'  |  0  if  rt  >  Pi  (not -killed). 

Once  all  the  components  are  assigned,  the  state  of  the  fault  tree  itself  can  be  determined.  This  is  accomplished  by 
breaking  it  down  into  its  arrangement  of  series  and/or  parallel  subsystems  and  systematically  evaluating  each  of 
these.  First  consider  a  system  consisting  of  just  two  components,  a  and  b,  arranged  in  series.  The  system  will  be 
killed  (i.e.,  no  complete  path  from  top  node  to  the  bottom  node  of  the  deactivation  diagram)  if  and  only  if  either  a  is 
killed,  or  b  is  killed,  or  both  are  killed.  Next  consider  a  system  consisting  of  two  components,  a  and  b,  arranged  in 
parallel.  This  system  will  be  killed  if  and  only  if  both  a  and  b  are  killed.  This  means  that  the  OR  operator,  | ,  will 
represent  two  components  in  series  and  the  AND  operator,  &,  will  represent  two  components  in  parallel,  as  demon¬ 
strated  in  Table  2.  For  completeness,  we  also  include  the  XOR  (exclusive  or)  operator,  which  is  true  only  when 
one  or  the  other  is  true,  but  not  both. 


Table  2.  Truth  table  for  series,  parallel,  and  exclusive  OR. 


Component 

Series 

Parallel 

Exclusive  OR 

a 

b 

a  |  b 

a  &  b 

a  ~  b 

0 

0 

0 

0 

0 

0 

1 

1 

0 

1 

1 

0 

1 

0 

1 

1 

1 

1 

1 

0 

The  beauty  of  this  method  is  its  simplicity.  For  example,  the  C  code  to  evaluate  the  fault  tree  depicted  in  Figure  1  is 

system  -  a  I  (  (  b  |  c  )  6  (  d  &  e  )  );  -  » 

Parentheses  perform  the  function  of  grouping  the  components  into  simple  series  and  parallel  subsystems.  In  this 
way,  it  is  very  straightforward  to  write  the  C  code  to  evaluate  the  most  complicated  fault  tree,  since  it  is  nothing 
more  than  components  arranged  in  nested  series  and  parallel.  Indeed,  one  of  the  tools  will  do  this  automatically 
from  the  FTML  description  of  the  fault  tree.  The  downside  of  this  approach  is  that  one  needs  to  sample  the  compo¬ 
nents  and  evaluate  the  system  a  number  of  times  from  the  given  component  kill  probabilities  in  order  to  generate  sta¬ 
tistically  significant  results.  We  will  continue  this  discussion  of  the  pros  and  cons  of  the  Monte  Carlo  approach  after 
we  have  first  described  the  probability  algebra  approach. 
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4.2  Probability  Algebra 

In  this  approach  we  use  the  component  kill  probabilities  directly.  If  pa  represents  the  probability  that  component  a 
is  killed,  and  pb  represents  the  probability  that  component  b  is  killed,  then  the  kill  probabilities  for  series,  parallel, 
and  exclusive  OR  arrangement  are  given  in  Table  3.  It  should  be  emphasized  that  these  formulas  are  strictly  valid 
only  when  there  is  independence  (i.e.,  no  correlation)  among  the  individual  kill  probabilities. 


Table  3.  Kill  probabilities  for  series,  parallel  and  exclusive  OR. 


Combination 

Expression 

Series 

1-V-PaXl-Pb) 

Parallel 

PaPb 

Exclusive  OR 

PaO-Pb)  +  PbV-Pa) 

To  make  these  expressions  as  simple  to  use  and  as  transparent  to  verify  as  the  Boolean  expressions,  we  encapsulate 
the  probability  algebra  into  a  C++  class,*  as  summarized  in  Table  4. 


Table  4.  Probability  algebra  with  the  Prob  class. 


Operation 

Mathematical  Notation 

Computer  Code 

Definition 

Let  p  be  a  probability, 
where  0  <  p  <  1 

Prob  p; 

assert ( 0<=p&&p<=l) ;a 

Let  p  =  0. 5 

Prob  p(  0.5  ) ;  or 

Prob  p  -  0.5; 

Logical  OR 

i-a-p0)(i-Pi) 

a  |  b; 

Logical  OR  assignment 

pa  <=  1-il-PaKl-Pb) 

a  |=  b; 

Logical  AND 

PaPb 

a  &  b; 

Logical  AND  assignment 

Pa  <=  PaPb 

a  &=  b; 

Logical  EXCLUSIVE  OR 

PaV~Pb)  +  (l  ~Pa)Pb 

a  ~  b; 

Logical  EXCLUSIVE  OR  assignment 

Pa<=  Pa(i~  Pb)  +  Q-Pa)Pb 

a  ^  =  b ; 

Logical  NOT 

1  -P 

l  p ;  or 

~p; 

Input  a  probability  p 

NA 

cin  »  p; 

Output  a  probability  p 

NA 

cout  «  p; 

Assign  one  probability  to  another 

Let  Pb  =  Pa  or 

Pb<=Pa 

b  -  a;  or 
b(  a  ); 

Addition 

Pa  +  Pb 

a  +  b; 

Addition  assignment 

Pa  *=  Pa  +  Pb 

a  +-  b; 

Subtraction 

Pa-Pb 

a  *  b; 

Subtraction  assignment 

pa  ^  Pa  —  Pb 

a  -=  b; 

Multiplication  by  a  scalar  s 

pb  =  sp0  or 

Pb  ~  Pa  & 

b  =  s  *  a;  or 
b  =  a  *  s; 

Multiplication  assignment 

pa<=s  Pa  or 

Pa  <=  Pa 

Division  by  a  scalar  s 

pis 

P  /  s; 

Division  assignment 

p  <=  pis 

P  /=  s; 

Check  for  equality 

Is  it  true  that  pa  =  pbl 

a  ==  b ; 

Check  for  inequality 

Is  it  true  that  pQ  *  pbl 

a  !  =  b; 

a  It  is  not  necessary  for  the  user  to  explicitly  code  this  assertion,  as  the  Prob  class  constructor  enforces  it  automatically. 
Note:  NA  =  not  applicable. 


*  Defining  a  class  in  C++  effectively  extends  the  language,  so  that  variables  that  are  now  declared  Prob  can  be  used  just  as  easily  as  native  types 
such  as  int  or  bool. 
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This  C++  class  gives  us  the  ability  to  use  the  same  simple  expressions  in  the  computer  code  regardless  of  whether 
the  components  are  being  represented  by  discrete  Boolean  states  or  by  continuous  probabilities.  This  makes  it  very 
easy  to  verify  fault  tree  coding —  where  we  would  otherwise  be  confused  by  a  sea  of  parentheses.  To  take  a  simple 
example,  the  coding  of  Figure  1  is  p  =  1  -  (1  -  pa){\  -  (1  -  (1  -  pb)(  1  -  pc))PdPe\  using  parentheses  only  where 
they  are  essential!  Using  the  Prob  class,  p  =  a  |  (  (  b  |  c  )  s  (  d  s  e  )  ). 

However,  there  is  an  important  issue  that  must  be  addressed  in  this  probability  approach — which  is  not  an  issue  with 
the  Monte  Carlo  approach —  and  that  is  the  problem  of  repeated  components. 


4.3  How  to  Handle  Repeated  Components 

Consider  the  deactivation  diagram  shown  in  Figure  7,  where  component  a  has  been  repeated. 


Figure  7.  Deactivation  diagram  with  repeated  component. 


The  Bradley  A2  degraded  states  [5]  deactivation  diagrams  are  expressed  in  this  manner.  It’s  important  to  realize  that 
the  diagram  expresses  the  logical  arrangement  of  components,  and  not  their  actual  physical  arrangement.  One  will 
get  the  wrong  answer  if  this  is  not  taken  into  account.  If  component  a  gets  killed,  for  instance,  then  it  gets  killed 
everywhere.  To  properly  evaluate  fault  trees  with  repeated  components,  we  factor  out  the  repeated  component  and 
systematically  reduce  the  fault  tree  to  a  sum  of  simpler  fault  trees  that  have  no  repeated  component.  We  can  factor 
out  the  dependence  on  component  a,  as  depicted  in  Figure  8. 


Figure  8.  Decomposition  of  repeated  component  diagram. 

The  component  a  is  either  killed,  in  which  case  we  have  the  diagram  on  the  left,  or  it  is  not  killed,  in  which  case  we 
have  the  diagram  on  the  right.  The  probabilities  are  additive  because  this  decomposition  represents  a  partition  of  the 
probabilities  into  disjoint  cases  of  either  a  (with  probability  a)  or  !a  (with  probability  l -  a).  The  diagram  on  the  left 
is  killed  (i.e.,  no  complete  path  from  top  node  to  bottom  node)  if  and  only  if  either  b  or  c  is  killed.  The  diagram  on 
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the  right,  on  the  other  hand,  already  has  a  completed  path,  regardless  of  the  state  of  b  or  c,  and  thus  cannot  be  killed 
(i.e.,  its  kill  state  is  0).  Therefore,  the  diagram  evaluates  to 

a  (  b  1  c  )  +  (1  -  a)  (  0  )  =>  a  s  (  b  |  c  ) . 


Figure  9.  Equivalent  diagram  without  repeated  component. 


Now,  this  example  is  simple  enough  that  we  could  easily  recognize  the  diagram  in  Figure  7  could  be  replaced  by  the 
diagram  in  Figure  9.  But  the  fact  remains  that  this  method  of  factorization  of  repeated  components  and  systematic 
decomposition  into  simpler  diagrams  can  always  be  carried  out.  Formally,  if  A  represents  the  diagram  in  Figure  7, 
and  f(a,  b,  c)  is  the  function  defined  by  the  expression  (  a  &  b  )  |  (as  c  ),then 

A  =  f(a,  b,  c) 

=  af(  1,  b,  c)  +  (1  -  a)/( 0,  b,  c) 

=  a[(  1  s  b  )  |  (  l  s  c  )]  +  (l-a)[(  0  &  b  )  |  (  0  s  c  )] 

=  a[b  |  c]  +  (l  -a)[0  |  0] 

=  a(b  1  c) 

=>  a  &  (  b  |  c  ),  (1) 

where  we  have  made  use  of  the  correspondence  between  the  Boolean  expression  and  probability  algebra  summa¬ 
rized  in  Table  5. 


Table  5.  Correspondence  between  Boolean  expression  and  probability  algebra. 


Next,  suppose  that  the  function  f(a,  b,  c)  represents  a  diagram  where  both  components  a  and  b  are  each  repeated. 
Then,  the  factoring  and  decomposition  proceeds  as  follows: 


/(a,  b,  c)  =  af{\ ,  b,  c)  +  (1  -  a)  f(0,  b,  c ) 

=  a[bf(  1 , 1,  c)  +  (1  -  b)f(  1 , 0,  c)]  +  (1  -  a)[bf(0, 1 ,  c)  +  (1  -  b)f( 0, 0,  c)] 

=  abf(  1, 1,  c)  +  fl(l  -  *)/(!, 0, c)  +  (1  -  a)bf( 0,  l,c)  +  (1  -  a)(l  -  h)/(0, 0,  c) 

resulting  in  four  terms.  Finally,  suppose  that  all  three  components  are  repeated.  This  will  produce  23  =  8  terms: 

f(a,  b,c)  =  (l-a)(l-  b)(  1  -  c)/(0, 0, 0)  +  (1  -  a)(l  -  b)cf( 0, 0, 1)  + 
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(1  -  a)b(  1  -  c)/(0, 1,0)  +  (1  -  a)fec/(0, 1,1)  + 
a(  1  -  b)(l  -  c)/(l,  0,0)  +  a(1  -  fr)c/(l,  0, 1)  + 
ai(l  —  c)/(l,  1,0)  +  a&c/(l,l,  1). 


This  can  also  be  written  as 


/(a,  b,c)=£  £  £  o'U  -  ay-'Vd  -  *)  Wc*(l  -  c)'~kf(i,  j,  k), 

i=0j=0k=0 

with  an  obvious  generalization  to  n  components,  alt  •  •  • ,  an: 
f(aua2r-,a„)=  £  £  •••  £ 

*i=0ij=0  i„=0 


1  ’ *n)  • 


(2) 


(3) 


With  the  Prob  class,  evaluation  of  fault  trees  is  simple.  For  example,  suppose  that  a  system  is  defined  by  the  follow¬ 
ing  function: 

Prob  systems  vector<  Prob  >  p  )  { 

return::-"'  •>.; 

.  Pioj  :  .  //a  • 


(  Ptl] 

I  ::: 

pm 


Pt3) 


i 

)i 

r 


//  b 
//  c 


//  d 
//  e 


This  can  be  evaluated  by  simply  calling  the  function 

system (  p  ) ;  ’  . 

But  now  consider  the  case  where  one  or  more  components  occur  more  than  once  in  the  fault  tree.  Let’s  say  b  is 
repeated: 

Prob  system!  vector<  Prob  >  p  )  { 
return 

Pl0)  //a 

I  ...  .  ;  .  '  .:  ■ 

(  .  .  .  :.  ..  . 

c  pm  //  b 

.  I  .  :.+  .  .  :  :.  v  '  ■■  '  .  - 

pm  //  c 

)  .  ..  ::  .  •: 

6  '  '  '  '  :  i .  ^  ^  'V  i,"A.  V*  J' 

p{ll  //  b  again 

& 

Pf 3J  // d 

) 

);  :  '  V'.; 

} 


We  will  get  the  wrong  answer  unless  we  account  for  this  repeated  component.  This  prompts  us  to  extend  the  Prob 
class  and  develop  methods  that  handle  any  number  of  repeated  components.  The  result  of  these  efforts  is  summa¬ 
rized  in  Table  6. 
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Table  6.  Probability  methods  with  the  Prob  class. 


Description 

Mathematical  Notation 

Computer  Code 

Probability  of  exactly  zero 
kills,  given  N  individual  kill 
probabilities  pt 

no -P,-) 

i=l 

vector<  Prob  >  p; 
zero(  p  ) ;  or 
none(  p  ) ;  or 
prob{  p,  0  ); 

Probability  that  all  are  killed, 
given  N  individual  kill  prob¬ 
abilities  Pi 

N 

YlPi 

i=l 

vector<  Prob  >  p; 
all  (  p  )  ;  or 
prob(  p,  p.size()  ); 

Probability  that  exactly  (any) 
n  items  are  killed,  given  N 
individual  kill  probabilities 
Pi,  where  1  <  n  <  N 

Z  •••  Z  Pid - •••/#(!- pn)1'1" 

ii=0  is-  0 

such  that  fj  +•••  +  !„  =  it 

vector<  Prob  >  p; 
prob  (  p ,  n  ) ;  or 
prob  (  p ,  n ,  ANY  ) ; 

Probability  that  n  or  more 
items  are  killed,  given  N 
individual  kill  probabilities 
Pi,  where  1  <  n  <  N 

z  z  pin\-pJ-h-piNU-pN)'->N 

h  =0  is  -0 

such  that  n  <  ix  +  •  ■  •  +  in  <  N 

vector<  Prob  >  p; 
prob(  p,  n,  OR_MORE) ; 

Probability  that  n  or  less 
items  are  killed,  given  N 
individual  kill  probabilities 
Pi,  where  1  <  n  <  N 

z  i  pi'd-  pi)1-’'1  •  •  •  pfca  -  pN 

<1=0  i«  =0 

such  that  1  <i  ij  +  •  •  •  +  in  <  n 

vector<  Prob  >  p; 
prob  (  p ,  n ,  OR__LESS  )  ; 

Probability  that  n  adjacent 
items  are  killed,  given  N 
individual  kill  probabilities 
Pi,  where  \  <  n<  N 

z  -  z  Pii(i-Pi)w'-P,^i-Pv)1-i" 

*i=0  is-  0 

such  that  i’i  +•••  +  /„  =  ft 

and  ii,*-*, i„  are  consecutive  indicies 

vector<  Prob  >  p; 
prob  ( p ,  n ,  ADJACENT ) ; 

Probability  that  n  non-adja- 
cent  items  are  killed,  given 

N  individual  kill  probabili¬ 
ties  ph  where  1  <  n  <  N 

z  ■  •  •  z  pi‘d  -  Pi)1_i'  •  •  •  pjy (i  -  pN)l'iN 

f‘i  =0  is  -0 

such  that  ii  +  — h  =  n 

and  *i » •  •  • » are  not  consecutive  indicies 

vector<  Prob  >  p; 

prob  ( p ,  n ,  NON_AD JACENT  )  ; 

Probability  that  a  system 
f(Pi*  P2’ ' " ' ,  Piv)  is  killed, 
given  the  individual  (non-re¬ 
peating)  kill  probabilities 

/(Pl>P2j,,,»Piv) 

where  no  p,  occurs  more  than  once 

Prob(*f )  (vector<Prob>)  ; 
vector<  Prob  >  p; 
f(  P  );  or 
evaluate (  f ,  p  ) ; 

Probability  that  a  system 
f(Pi,P2>---,pN)  is  killed, 
given  that  only  one  index,  i, 
occurs  more  than  once 

/(Pl»P2»",*Piv) 

where  only  index  i  occurs  more  than  once 

Prob  ( * f )  ( vector<Prob>  )  ; 
vector<  Prob  >  p; 
evaluate (  f,  p,  i  ); 

Probability  that  a  system 
/(Pi»P2."',Pw)  is  killed, 
given  that  many  indicies 
occur  more  than  once 

/(Pi.P2»-">Piv) 

where  indicies  iif •••,*«  occur  more  than 
once 

Prob(*f )  (  vector<Prob> )  ; 
vector<  Prob  >  p; 
vector<  int  >  i; 
evaluate (  f,  p,  i  ) ; 

Probability  that  a  system 
f(Pi>P2<---,pN)  is  killed, 
making  no  assumptions 
about  repeated  indicies 

/(PuPi^-'iPn) 

where  any  or  all  of  the  indicies  may  occur 
more  than  once 

Prob(*f )  ( vector<Prob>  )  ; 
■vector<  Prob  >  p; 
evaluate_all  (  f ,  p  ) ; 

With  these  methods,  the  case  considered  last  is  simply 
evaluate (  system,  p,  1  ) ; 


since  1  is  the  repeated  index. 
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4.4  How  to  Handle  Circular  Dependency  of  Fault  Trees 

Beyond  the  problem  of  lack  of  independence  among  components  due  to  their  repeated  occurrence  is  the  problem  of 
cyclic  dependence  among  fault  trees.  One  finds  instances  of  this  in  the  Abrams  M1A2  criticality  analysis  [6],  so  it  is 
a  real  issue  that  must  be  dealt  with.  Consider  a  simple  example,  as  illustrated  in  Figure  10. 


Figure  10.  Example  of  cyclic  dependence  among  fault  trees. 


In  terms  of  Boolean  logic,  the  state  of  each  diagram  is  easy  to  express  in  code: 

A  -  a  |  (  b  S  B  ); 

B  “  C  (k  C} 

C  “  d  |  k; 

But  in  order  to  evaluate  system  A,  we  need  to  know  system  B,  which  involves  system  C,  and  that,  in  turn,  involves 
system  A  again.  Each  system  is  defined  recursively,  and  we  don’t  seem  to  be  able  to  get  started. 

But  it’s  also  possible  to  write  down  the  kill  probabilities  for  each  diagram: 

pA  =  l~(l-Pa)(l~PbPB)> 

Pb  =  PcPc  > 

pc  =  l-(l-^)(l-pi4). 

This  is  simply  a  system  of  three  equations  in  three  unknowns,  which  is  easily  solved: 

_  1  (1  ~  Pa)U  - Pb  +  Pb(\  ~  Pc)] 

PA  1“(1  -  Pa)PbPc(l"Pd) 

P5  =  Pc~Pc(l““Prf)(l-Pl)> 

PC  sr  1  —  (1  —  Pd)(l  ~  pi)  . 

So,  it’s  clear  that  there  is  indeed  a  solution,  and  the  problem  is  well  defined.  The  problem,  though,  is  that  we  would 
rather  not  have  to  perform  this  algebra.  This  example  happens  to  be  very  simple;  a  real  criticality  analysis  can 
involve  many  more  than  three  fault  trees,  where  each  fault  tree  can  involve  many  more  components,  resulting  in 
some  very  messy  algebra. 

But  the  fact  that  the  problem  is  well  defined  leads  to  another  approach.  Notice  that  no  matter  how  complicated  each 
system  may  be,  they  are  still  probabilities,  and  as  such,  must  lie  between  0  and  1.  Consequently,  we  could  try  find¬ 
ing  a  solution  by  iteration  using  either  a  Newton-Rhapson  or  bisection  algorithm.  But  a  better  idea  is  to  simply  use 
recursion.  The  idea  here  is  that  we  initially  assign  kill  probabilities  to  each  of  the  systems  involved  in  the  cyclic 
dependence  and  then  iterate  a  number  of  times  until  each  of  the  system  probabilities  converges  to  a  solution.  It  turns 
out  that  this  seems  to  work  well  and  is  very  easy  to  implement.  For  example,  here  is  the  code  for  this  example: 
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Prob  A(  O'.  ),  B(  0.  ),  C(  0.  );  :  //  using  0  probabilities  as  a  starting  point 

const  int  N_ITERATI ONS  *  15;  //  number  of  iterations 

for  (  int  i  -  0;  i  <  N_ITERATIONS;  i++  )  { 

A  =  a  |  (  b  SB  );  .  .  S;  ;,v-: 

B  =  c  &  C;  ■  ; 

C  «  d  I  A;  J-T'. ■ 

} 

By  trial  and  error,  fifteen  iterations  were  found  to  be  more  than  sufficient,  not  only  for  this  example,  but  also  for 
many  others  that  were  tried,  including  the  Abrams  criticality  analysis  which  involved  dozens  of  fault  trees. 

Monte  Carlo  sampling,  in  which  components  and  systems  are  represented  by  Boolean  variables,  can  also  deal  with 
cyclic  dependence  using  this  same  principle  of  recursion: 

bool  A<  0  ),  B(  0  ),  C<  0  );  //  using  0  Booleans  as  a  starting  point 

const  int  N„ITERATIONS  =15;  //  number  of  iterations 

for  (  int.  i  -  0;  i  <  ^.ITERATIONS;  i++  )  ( 

A  -  a  I  (  b  &  B  ); 

B  =  c  &  C; 

C  =  d  |  A; 

i  '  -a  ...  ■  •  ,  >v:;  .  ,  -  ( 

This  effectively  primes  the  systems,  and  this  becomes  the  starting  point  for  gathering  statistics.  This  procedure 
amounts  to  taking  N  + 15  samples,  but  then  performing  the  statistics  on  the  last  N. 

4.5  Comparison  of  Monte  Carlo  Sampling  and  Probability  Algebra 

The  coding  for  normal  fault  trees,  which  have  no  repeated  components  and  no  cyclic  dependencies,  is  the  same  for 
both  methods,  only  the  variable  declaration  is  different  (bool  for  the  Monte  Carlo  method  and  Prob  for  the  proba¬ 
bility  algebra  approach).  Table  7  summarizes  the  differences  between  the  two  approaches. 


Table  7.  Comparison  of  Monte  Carlo  sampling  and  probability  algebra. 


Issue 

Monte  Carlo  Sampling 

Probability  Algebra 

Component  Representation 

Discrete  killed  or  not-killed 

Continuous  kill  probability 

Accuracy 

Increases  with  the  number  N  of 
samples,  but  no  better  than  AT1 

Exact 

Able  to  handle  dependencies 
among  components? 

Yesa 

Noa 

How  to  handle  repeated 
components 

Done  automatically 

Identify  components  and  call  the 
appropriate  class  method 

How  to  handle  cyclic  dependence 

Slight  increase  in  number  of  samples 

Iterate  small  number  of  times  first 

Requirements 

Random  number  generator 

Prob  class 

Speed  with  a  normal  fault  tree 

Depends  on  number  of  samples,  but 
each  sample  is  very  fast 

Fast 

Speed  with  repeated  components 

Not  any  slower  than  normal  case 

Could  be  significantly  slower 

Speed  with  cyclic  dependence 

Negligibly  slower  than  normal  case 

Negligibly  slower  than  normal  case 

*  The  component  dependency  issue  merits  some  elaboration.  Let’s  suppose  that  every  time  component  a  is  killed,  component  b  is  not,  perhaps 
due  to  mutual  shielding.  So  every  time  that  a  is  1,  b  is  0,  and  vice  versa.  If  the  component  state  vector  is  a  Boolean  vector  of  l’s  and  0’s,  then 
the  Monte  Carlo  approach  would  reflect  this  dependency.  However,  the  component  state  is  usually  not  (never?)  in  this  form.  Rather,  it  is  a  pk 
vector  of  component  kill  probabilities.  This  vector  contains  no  information  regarding  dependencies  or  correlations  among  the  components, 
and,  consequently,  the  Monte  Carlo  method  would  not  be  able  to  extract  any.  So,  for  all  practical  purposes  with  current  MUVES  runs,  neither 
method  handies  dependencies  among  components  because  it  is  not  contained  in  the  input.  Nevertheless,  the  Monte  Carlo  approach  is  capable 
of  dealing  with  dependencies,  whereas  the  probability  algebra  approach  described  here  is  not  because  it  assumes  independence. 
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5.  FAULT  TREE  BROWSER 

The  Web-scripting  language  of  PHP  is  particularly  well-suited  for  writing  applications  based  on  FTML,  for  two  pri¬ 
mary  reasons: 

•  PHP  was  and  is  designed  for  the  Web,  with  a  rich  set  of  features  that  support  a  number  of  technologies  includ¬ 
ing  XML,  graphics,  and  PDF. 

•  It  is  also  an  interpreted  language — which  means  that  it  doesn’t  need  to  be  compiled  first — and  this  results  in  a 
very  interactive  environment  for  the  user. 

The  combination  of  FTML  and  PHP  makes  it  possible  to  design  interactive  software  for  displaying  in  a  Web  browser 
or  for  generating  other  interactive  (PDF)  documents.  Here  we  describe  one  such  application,  a  Fault  Tree  Browser 
for  viewing  a  criticality  analysis. 

After  the  individual  FTML  files  have  been  assembed  into  a  criticality  analysis  (as  explained  in  section  3.3),  we 
would  like  to  be  able  to  browse  through  the  complete  set  of  fault  trees.  This  is  the  purpose  of  the  Fault  Tree 
Browser.  The  home  page  for  this  application  is  shown  in  Figure  11. 


Figure  11.  Fault  tree  browser  home  page. 


The  user  selects  the  particular  target  of  interest  and  the  desired  order  for  a  listing  of  its  various  systems.  These 
include  the  order  as  they  are  documented  in  an  existing  report  (i.e.,  by  figure  number),  alphabetical  order  by  system 
name,  or  the  order  in  which  they  depend  upon  one  another.  In  the  last  case,  the  ordering  is  done  by  making  sure  that 
if  system  A  depends  upon  system  B,  then  system  B  is  listed  before  system  A.  This  ordering  is  important  for  proper 
initialization,  and  with  the  number  of  dependent  systems  in  a  typical  criticality  analysis,  the  required  ordering  is  not 
at  all  obvious.  In  some  cases,  such  as  the  Abrams  M1A2,  it  is  even  possible  to  have  circular  dependencies.  The 
software  is  able  to  detect  this  and  isolate  all  those  systems  that  are  involved  in  circular  dependencies.  These  are 
reported  separately  from  all  the  other  systems  that  are  either  independent  of  one  another  or,  at  most,  have  sequential 
dependency.  There  are  two  types  of  output  that  are  supported:  deactivation  diagrams  for  viewing  the  fault  trees  or 
sysdefcode  that  is  useful  for  evaluating  the  fault  tree.  Finally,  the  user  has  the  option  of  either  displaying  the  results 
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in  a  Web  browser  or  generating  a  report  that  can  be  saved  or  printed.  The  last  two  options  will  be  described  more 
fully  later,  but  regardless  of  which  options  have  been  selected,  when  the  user  clicks  on  the  Go  button,  the  next  page 
to  appear  will  be  similar  to  that  shown  in  Figure  12. 


jj,X . ...  Systoraln 

FHe  Edit  View  Bo  Communicator 


jstsiaa 

Help 


Figure  12.  Listing  of  ail  the  systems  in  a  criticality  analysis. 


Here  we  see  a  listing  of  all  the  systems  that  constitute  the  criticality  analysis.  In  this  case,  they  are  arranged  in  sys¬ 
tem  dependency  order.  By  clicking  on  the  top  link,  “Display  the  Complete  Criticality  Analysis,”  the  complete  sys- 
def  code  for  all  the  systems  is  concatenated  together  and  displayed  in  the  browser.  The  page  can  then  be  saved  as  a 
text  file  and  used  in  other  codes  that  require  evaluation  of  the  fault  trees.  Notice  that  all  systems  are  links  and  by 
clicking  on  them,  the  user  is  automatically  taken  to  the  particular  sysdef  expression  for  that  system,  an  example  of 
which  is  shown  in  Figure  13. 
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Figure  13.  Sysdef  code  with  links. 


By  clicking  on  the  links  and  the  Back  button  of  the  browser,  it  is  easy  to  navigate  through  the  criticality  analysis. 

If  we  return  to  the  home  page  and  select  the  Deactivation  Diagram  option,  then  we  are  again  presented  with  a  list  of 
systems  similar  to  the  one  in  Figure  12.  But  now,  clicking  on  a  system  will  bring  up  the  corresponding  deactivation 
diagram.  An  example  of  which  is  shown  in  Figure  14. 
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Figure  14.  Deactivation  diagram  in  fhult  tree  viewer. 


Empty  boxes  are  critical  components,  and  shaded  boxes  are  systems.  By  clicking  on  the  system  name  in  the  table, 
the  user  is  automatically  taken  to  that  particular  deactivation  diagram. 


Finally,  by  returning  to  the  home  page  and  selecting  Generate  PDF  Document,  a  PDF  document  is  constructed  that 
has  one  deactivation  diagram  per  page.  An  example  is  shown  in  Figure  15. 
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Figure  15.  Page  of  generated  PDF  document. 


Here,  the  Adobe  Acrobat  Reader  is  installed  as  a  plug-in  so  that  the  resulting  PDF  document  is  loaded  directly  in  the 
browser.  If  the  user  has  not  installed  the  plug-in,  then  the  browser  would  bring  up  a  dialog  box  requesting  die  user 
to  save  the  PDF  file.  Notice  that  the  system  boxes  are  shaded  in  the  PDF  document.  These  are  links  embedded 
directly  in  the  PDF  document  and  can  be  used  to  navigate  through  the  criticality  analysis. 


It  should  be  emphasized  here  that  all  of  this  is  being  done  on  the  fly  from  just  the  FTML.  Deactivation  diagrams, 
sysdef  code,  and  PDF  documents  are  constructed  and  displayed  as  the  FTML  is  being  parsed;  nothing  has  been  pre- 
processed  ahead  of  time. 
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APPENDIX.  SOURCE  CODE  LISTING  OF  Prob  CLASS 


//  Prob.h:  Probability  Algebra  Class  for  the  Evaluation  of  Fault  Trees 

#ifndef  PROB_H 
#def ine  PROB_H 

#include  <lostream> 

# include  <vector> 

#include  <assert.h> 

# include  <math.h> 
using  namespace  std; 

//  list  of  valid  conditions 

static  const  int  ANY  =  0; 

static  const  int  ADJACENT  -  1; 

static  const  int  NON_ADJACENT  -  2; 

Static  const  int  NOT_ADJACENT  -  NON_AD JACENT  ; 

static  const  int  OR_MORE  -  3; 

static  const  int  OR_LESS  -  4; 

class  Prob  { 

static  const  bool  KILLED  -  true;  //  meaning  of  true 

Static  const  bool  NOT_KILLED  -  I  KILLED; 

//  friends  list  of  functions 

friend 

Prob  zero(  vector<  Prob  >  pk  )  {  //  probability  of  exactly  zero  kills 

double  prod  -  1 . ; 

for  (  int  i  -  0;  i  <  pk.size();  i++  )  prod  *«  !pk[  i  ]; 
return  Prob<  prod  ); 


friend 

Prob  none(  vector<  Prob  >  pk  )  {  //  synonymous  with  zero 

double  prod  -  1 . ; 

for  (  int  i  -  0;  i  <  pk.size{);  i++  )  prod  *-  1 pk [  i  ]; 
return  Prob(  prod  ); 


friend 

Prob  all(  vector<  Prob  >  pk  )  {  //  probability  of  exactly  all  killed 

double  prod  -  1 . ; 

for  (  int  i  -  0;  i  <  pk.size();  i++  )  prod  *-  pk[  i  ]; 
return  Prob (  prod  ) ; 


//  return  probability  of  exactly  n_kills  under  the  given  condition 
friend 

Prob  prob(  vector<  Prob  >  pk,  //  pk  vector 

int  n_kills,  //  number  of  kills 

int  condition  -  ANY  )  {  //  condition  w/  any  as  default 

int  n  -  pk.size( ) ; 

if  (  n„kills  --  0  &&  condition  —  ANY  )  return  zero(  pk  ); 

if  (  n_kills  —  n  &&  condition  —  ANY  )  return  all(  pk  ); 

double  p_adjacent  -  0.; 
double  p_not_adjacent  =0.; 

double  p  -  exact(  pk,  n_kills,  p_adjacent,  p_not_adjacent  )  ; 

switch  (  condition  )  { 

case  (  ANY  ) : 

return  Prob (  p  ) ; 
case  (  ADJACENT  ) : 

if  (  n_kills  <  2  )  return  Prob(  0.  );  //  requires  at  least  2 

return  Prob(  p_adjacent  ); 
case  (  NON_AD JACENT  ): 

if  (  n_kills  <  2  )  return  Prob(  0.  );  //  requires  at  least  2 

if  (  n_kills  —  n  )  return  Prob(  0.  );  //  non-adjacent  impossible 

return  Prob(  p_not_adjacent  ); 
case  (  OR_MORE  ) : 

for  (  int  i  “  n_kills+l;  i  <-  n;  i++  ) 

p  +=*  exact(  pk,  i,  p_adjacent,  p_not_adjacent  ); 
return  FroO (p); 
case  (  OR_LESS  ) : 

for  (  int  i  -  0;  i  <  n_kills;  i++  ) 

p  +=  exact(  pk,  i,  p_adjacent,  p_not_adjacent  ); 
return  Prob (  p  ) ; 
default: 

cerr  «  "invalid  condition:  "  «  condition  «  endl; 
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exit(  1  ); 

} 

} 

//  return  probability  of  exactly  n_kills  (both  adjacent  and  non-ad jacent) 
friend 

Prob  exact  (  vector <  Prob  >  pk,  //  pk  vector 

int  n_kills,  //  number  of  kill 

doubles  p_ad jacent,  //  probability  of  exactly  n^kills,  adjacent  onl 

doubles  p_not_ad  jacent  )  {  //  probability  of  exactly  n_kills,  non-ad  jacent  only 

int  n  -  pk.size(); 

if  (  n^kills  <  0  )  { 

cerr  «  "The  number  of  kills  of  interest,  "  «  n_kills 
«  ",  must  be  zero  or  greater"  «  endl; 
exit(  1  ) ; 

} 

if  (  n_kills  >  n  )  { 

cerr  «  "Impossible  since  the  number  of  kills  of  interest,  "  «  n_kills 
«  ",  exceeds  the  number  of  elements,  "  «  n  «  endl; 
exit{  1  ); 

} 

vector<  Prob  >  p  -  pk; 
vector<  bool  >  bit(  n  ); 
p_ad jacent  -  0.; 
p_not_ad jacent  -  0.; 

for  (  unsigned  int  i  -  0;  i  <  pow(  2,  n  );  i++  )  { 

_decode(  i,  bit  ); 
int  count  -  0; 

for  (  int  j  -  0;  j  <  n;  j++  )  count  +-  bit[  j  ]; 

if  (  count  J-  n_kills  )  continue; 

bool  adjacent  -  false; 
if  (  n_Jcills  —  n  ) 
adjacent  -  true; 
else  { 

for  (  int  j  -  0;  j  <  n  -  n_kills  +1;  j++  )  { 
bool  ex  -  true; 

for  (  int  k  -  0;  k  <  n_kills;  k++  )  ex  bit[  j  +  k  ]; 
adjacent  )«  ex; 

} 

} 


double  prod  -  1 . ; 
for  (  int  k  -  0;  k  <  n;  k++  )  { 
if  (  bit (  k  ]  )  p[  k  ]  -  pk [  k  ] ; 

else  p[  k  ]  -  !pk [  k  ]; 

prod  *-  p[  k  }; 

} 

if  (  adjacent  )  p_ad jacent  +«  prod; 

else  p_not_ad jacent  +-  prod; 

} 

return  Prob(  p_ad  jacent  +  p_not_ad jacent  ); 


friend 

Prob  evaluate (  Prob(  *ft  )(  vector<  Prob  >  ),  //  function  pointer  to  fault  tree 

vector<  Prob  >  pk  )  {  //  pk  vector 

return  ft{  pk  ); 

} 


friend 

Prob  evaluate (  Prob(  *ft  )(  vector<  Prob  >  ),  //  function  pointer  to  fault  tree 

vector<  Prob  >  pk,  //  pk  vector 

int  index  )  {  //  one  repeated  index 

assert (  0  <-  index  &&  index  <  pk.size()  ); 
vector <  Prob  >  p  -  pk; 

double  el  -  pk [  index  ] ; 
double  e2  -  lpk[  index  ]; 

p[  index  3  -  KILLED; 
double  pi  -  el  *  ft(  p  ); 


p[  index  ]  -  NOT__KILLED; 
double  p2  -  e2  *  ft(  p  ); 

return  Prob (  pi  +  p2  ) ; 


friend 

Prob  evaluate(  Prob(  *ft  )(  vector<  Prob  >  ), 
vector<  Prob  >  pk, 
int  indexl, 
int  index2  )  { 


//  function  pointer  to  fault  tree 
//  pk  vector 
//  first  repeated  index 
//  second  repeated  index 
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assert(  0  <«  indexl  ss  indexl  <  pk.size()  ); 
vector<  Prob  >  p  “  pk; 

double  el  -  pk  [  indexl  ]  ; 
double  e2  -  !pk[  indexl  ]; 

pt  indexl  ]  ~  KILLED; 

double  pi  -  el  *  evaluate(  ft,  p,  index2  ); 
p[  indexl  ]  -  NOT_KILLED; 

double  p2  -  e2  *  evaluate(  ft,  p,  index2  ); 
return  Prob  (  pi  +  p2  )  ; 


friend 

Prob  evaluate (  Prob(  *ft  )(  vector<  Prob  >  ),  //  function  pointer  to  fault  tree 

vector<  Prob  >  pk,  //  pk  vector 

vector<  int  >index  )  {  //  repeated  index  vector 

int  m  -  index. size( ) ; 
int  n  -  pk.size( ) ; 
assert(  0  <=  m  &s  m  <“=  n  ) ; 

if  (  m  —  0  )  return  evaluate(  ft,  pk  ) ;  //  no  index  occurs  more  than  once 

if  (  m  —  1  )  return  evaluated  ft,  pk,  index[  0  J  );  //  only  one  index  occurs  more  than  once 

if  (  m  —  n  )  return  evaluate_all (  ft,  pk  );  //  all  indices  occur  more  than  once 

int  indexl  «  index .back( ) ;  //  get  last  index 

assert(  0  <-  indexl  ss  indexl  <  pk.size()  ); 
index .pop_back( ) ;  //  decrement  the  index  vector 

vector<  Prob  >  p  =  pk; 

double  el  -  pk [  indexl  ] ; 
double  e2  -  lpk[  indexl  ]; 

p[  indexl  ]  -  KILLED; 

double  pi  -  el  *  evaluate(  ft,  p,  index  ); 

p[  indexl  ]  -  NOT_KILLED; 

double  p2  -  e2  *  evaluate(  ft,  p,  index  ); 

return  Prob(  pi  +  p2  ); 


//  evaluate  without  making  any  assumptions  regarding  repeated  indices 

//  gives  correct  answer  even  if  not  all  indices  are  repeated,  but  does  take  longer 

friend 

Prob  evaluate_all (  Prob(  *ft  )(  vector<  Prob  >  ),  //  function  pointer  to  fault  tree 

vector<  Prob  >  pk  )  {  //  pk  vector 

int  n  -  pk,size( ) ; 

vector<  Prob  >  p(  n  ),  state (  n  ); 

vector<  bool  >  bit(  n  ); 

double  prob  -  0 . ; 

for  (  int  i  -  0;  i  <  pow(  2,  n  );  i++  )  { 

..decode  (  i,  bit  ); 

double  prod  -  1 . ; 

for  (  int  j  -  0;  j  <  n;  j++  )  { 

if  (  bit[  j  3  )  pt  j  1  -  pk|  j  j; 
else  Pi  j  ]  -  ! pk [  j  ]; 

prod  *-  p[  j  ] ; 

state l  j  ]  *=  Prob(  bit[  j  ]  ); 

} 

prob  +-  prod  *  ft(  state  ) ; 

} 

return  Prob(  prob  ); 


//  overloaded  logical  operators 

friend  Prob  operator |(  const  Probs  a,  const  Probfi  b  )  {  //  logical  OR 

return  Prob(  a._p  +  b._p  -  a._p  *  b._p  ); 

} 

friend  Prob  operators (  const  Probs  a,  const  Probs  b  )  {  //  logical  AND 

return  Prob(  a._p  *  b._p  ); 

} 

friend  Prob  operator" (  const  Probs  a,  const  Probs  b  )  {  //  logical  EXCLUSIVE  OR 

return  Prob(  a._p  +  b._p  -  2.  *  a._p  *  b._p  ); 

} 

//  overloaded  arithmetic  operators 

friend  Prob  operator+(  const  Probs  a,  const  Probs  b  )  {  //  Prob  +  Prob 

return  Prob(  a._p  +  b._p  ); 

} 
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friend  Prob  operator+(  const  Probs  a,  double  b  )  {  //  Prob  +  double 

return  Prob(  a._j?  +  b  ); 

} 

friend  Prob  operator+(  double  a,  const  Probs  b  )  {  //  double  +  Prob 

return  Prob(  a  +  b._p  ); 

} 

friend  Prob  operator- (  const  Probs  a,  const  Probs  b  )  {  //  Prob  -  Prob 

return  Prob(  a._p  -  b._p  ); 

} 

friend  Prob  operator- (  const  Probs  a,  double  b  )  {  //  Prob  -  double 

return  Prob{  a._p  -  b  ); 

} 

friend  Prob  operator- (  double  a,  const  Probs  b  )  {  //  double  -  Prob 

return  Prob(  a  -  b._p  ); 

} 

friend  Prob  operator* (  const  Probs  a,  double  s  )  [  //  Prob  *  double 

return  Prob(  a._p  *  s  ); 

} 

friend  Prob  operator* (  double  s,  const  Probs  a  )  {  //  double  *  Prob 

return  Prob(  a._p  *  s  ); 

} 

friend  Prob  operator/(  const  Probs  a,  double  s  )  {  //  Prob  /  double 

assert (  s  >-  0.  ); 
return  Prob(  a._p  /  s  ); 


//  overloaded  stream  operators 

friend  istreams  operator»(  istreams  is,  Probs  a  )  [  //  input  Prob 

double  p; 

is  »  p;  //  enter  the  probability 
if  (0.  <-  p  ss  p  <-  1.  )  { 
a._p  -  p; 
return  is; 

} 

cerr  «  "Invalid  input:  value  must  be  between  0  and  1."  «  endl 
«  "Program  Stopped."  «  endl; 
exit(  1  ); 

} 


friend  ostreams  operator«(  ostreams  os,  const  Probs  a  )  {  //  output  Prob 

return  os  «  a._p; 

} 

public: 

Prob(  double  p  -  0.  )  {  //  constructor  with  default  of  zero 

assert(  0.  <-  p  &&  p  <-  1.  );  //  P  must  be  in  the  interval  [0,1] 

-P  -  P»* 

) 

~Prob(  void  )  {  //  default  destructor 

J 

Prob(  const  Probs  a  )  :  _p(  a._p  )  {  //  copy  constructor 

} 

Probs  operator- {  const  Probs  a  )  [  //  assignment  operator 

if  (  this  1-  sa  )  _p  -  a._p; 
return  *this; 


Probs  operator- (  const  doubles  p  )  {  //  assign  a  probability 

-P  -  p; 
xeLuin  •'t.hls; 


Prob  operator  I  (  void  )  {  //  logical  NOT 

return  Prob(  1.  -  _p  ) ; 

} 
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Prob  operator" (  void  )  {  //  logical  NOT 

return  Prob(  1.  -  _p  ) ; 

} 

//  overloaded  logical  operators 


Probfi  operator  1 «(  const  Prob&  a  )  { 

-P  (  1.  ‘  -P  )  *  a*— p; 

assert (  0.  <-  __p  &&  _p  <-  1.  ); 
return  *this; 


Probfi  operators- (  const  Probfi  a  )  { 
_P  *=  a . „p ; 

assert(  0.  <«=  _p  &&  _p  <=  1.  ); 
return  *this; 


Probfi  operator''- (  const  Probfi  a  )  { 

_p  +=  (  1.  ~  _p  -  _p  )  *  a._p; 

assert(  0.  <-  _p  &&  _p  <-  1.  ); 
return  *this; 


//  overloaded  arithmetic  operators 

Probfi  operator+-*(  const  Probs  a  )  { 
-P  +-  a .  __p  ; 

assert(  0.  <-  _p  &&  _p  <-  1 .  ); 
return  *this; 


Probfi  operator+-(  double  p  )  {  // 

_P  +*=  p; 

assert(  0.  <-  _p  &&  _p  <-  1 .  ); 
return  *this  ? 


Probfi  operator-- (  const  Probfi  a  )  { 
— P  —  a .  _p  ; 

assert(  0.  <-  _p  &&  _p  <«  1.  ); 
return  *this; 


Probfi  operator --(  double  p  )  {  // 


//  logical  OR  assignment 


//  logical  AND  assignment 


//  logical  EXCLUSIVE  OR  assignment 


//  addition  assignment  from  Prob 


addition  assignment  from  double 


//  subtraction  assignment  from  Prob 


subtraction  assignment  from  double 


-P  —  p; 

assert (  0.  <-  _p  &&  _p  <-  1 .  ); 
return  *this; 


Probfi  operator*- (  double  s  )  {  //  multiplication  assignment 

assert (  s  >-  0.  ); 

_P  *-  s; 
return  *this; 


Probfi  operator/- (  double  s  )  {  //  division  assignment 

assert (  s  >  0.  ); 

_P  /-  s; 
return  *thls; 


//  conversion  operator 

operator  double  (  void  )  const  {  //  return  probability  value 

return  _p; 

} 


//  access  functions 

double  p(  void  )  const  {  //  return  probability  value 

itJLuin  _p; 

] 

private: 

friend 

unsigned  int  _encode(  const  vector<  bool  >s  v  )  { 
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const  unsigned  int  BITS_PER_BYTE  -  8; 
const  int  N  -  v.size(); 

assert*  N  <-  BITS_PER_BYTE  *  sizeof*  unsigned  int  )  ); 
unsigned  int  a  -  (  unsigned  int  )(  v[  0  ]  ); 
for  (  int  i  -  1;  i  <  N;  s  +-  v[  i++  ]  )  s  *-  2; 
return  s; 


friend 

void  _decode{  unsigned  int  s,  vector<  bool  >&  v  }  { 

const  unsigned  int  BIT  -  1; 
const  int  N  -  v.size(); 
v  -  vector<  bool  >(  N,  false  ); 

for  (  int  i  -  0;  i  <  N;  i++  >  v[  N  -  1  -  i  ]  -  (  s  &  (  BIT  «  i  )  ) 


^  double  _p;  //  probability  value 

#endif 
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